1. Field of the Invention
The present invention generally relates to network security, and more specifically relates to an Internet Key Exchange (IKE) daemon self-adjusting negotiation throttle for minimizing retransmission processing during Security Association (SA) negotiation requests.
2. Related Art
The Internet Key Exchange (IKE) daemon dynamically negotiates Security Associations (SAs) for secure communication, known as IPSecurity. The IKE daemon follows the Internet Security Association and Key Management Protocol (ISAKMP) as specified in RFC 2408. Although two IKE daemons communicate by sending across User Datagram Protocol (UDP) messages, the ISAKMP protocol specifies and uses retransmissions to provide reliability.
A problem occurs when the IKE daemon attempts to negotiate a large numbers of SAs. Each SA negotiation involves a number of message exchanges. When a large number of SAs are being negotiated in parallel, message congestion may keep the IKE daemon from handling message requests in a timely manner. Delays in IKE daemon processing may lead to message retransmissions from the peer, which further exacerbates the problem. The IKE daemon detects the retransmitted messages as “replays,” since the message has already been received and processed. The additional work in processing replays in turn causes more retransmissions since the IKE daemon is congested and cannot process all the messages and send a reply quickly enough. This “snowball” effect continues until the IKE daemon is predominately performing useless work by examining retransmissions for messages already received. If unchecked, this could potentially lead to a program crash or consume all available operating system resources. Further, the IKE daemon is also sending out retransmissions to the IKE peer causing congestion for the IKE peer. This is a common problem that can occur when the IKE daemon is restarted, during machine outages, when rebooting, or when large numbers of clients require connections within a short period of time (e.g., large number of employees at a large company logging on at 8:00 AM).
A common solution to reduce the number of retransmissions is to include a backoff mechanism such as a binary exponential backoff mechanism. An example would be to send a retransmission after 5 seconds, 10 seconds, 20 seconds, and so on. While this may work to reduce retransmissions for a single SA negotiation, it does not help in cases where there are a large number of SA negotiations within a short interval of time. The initial retransmit interval for the backoff mechanism would likely be small and cause a large amount of retransmissions initially.
Accordingly, a need exists for a way to efficiently minimize the amount of retransmission processing and maximize the number of SA negotiations in a self-adjusting manner.